A simplification of this could be:

	LocalVariableNameFactory(Iterable<String> predefinedVariableNames) {
		predefinedVariableNames.forEach((paramName) -> variables.put(paramName, 0L));
	}

Wdyt?

Do we need to update the original intendedVariableName?

This code is fine but concurrency aside, I still think something like the following that would replace line62-86 would simplify things:

@Override
public String generateName(String suggestedName) {
	var counter = variables.compute(suggestedName,
			(__, currentCount) -> currentCount == null ? 0 : currentCount.longValue() + 1);
	return counter == 0 ? suggestedName : "%s_%s".formatted(suggestedName, counter));
}

I would suggest refining the way we approach the problem. We generally hold details in the context and can look these up. I would suggest that we keep a map around with parameter name mappings and use this method as getLocalVariableName(…) or localVariable(String logicalName). One could then call the method with the same name twice. On the first call, we would ensure there is no clash, the second call would return the mapped name. Would also alleviate the need to track the variable name in the calling code.

sorry I don't get that comment. Why would I want to call the same method twice?
you'll have to keep track of variable name in the calling code since you might have to apply it in different code blocks or have to pass it around between query creation and execution so you refer to right thing.

you'll have to keep track of variable name in the calling code since you might have to apply it in different code blocks or have to pass it around between query creation and execution so you refer to right thing.

Calling code would then not be required to track the actual variable name but could refer to the context so the context provides the information.

Nit: I liked the visibility modifiers to indicate which methods are desired API and to differentiate between those ones, that are package-private for testing purposes.